The present invention relates generally to computer software for displaying content on a computer display screen. More particularly, the present invention relates to computer software for displaying keyboard cues in a window portion of a computer display screen.
Many users of computer systems become frustrated with excessive screen clutter. Some users dislike an application window that is cluttered with unnecessary graphics. Dialog box windows especially tend to suffer from this problem. For example, some operating systems provide keyboard cues such as focus indicators and keyboard accelerators. A focus indicator is typically a dashed-line box drawn on the screen within a button or around text that currently has the focus of the window. The focus indicator aids keyboard users identify what function will be activated by depressing the xe2x80x9centerxe2x80x9d key on the keyboard. The focus indicator is unnecessary to users that rely heavily on a pointing device, such as a mouse, to input commands to the computer.
Keyboard accelerators are small lines that underline particular letters of words displayed in a control window. Usually, the underlined letter is depressed in combination with a keyboard key, such as the xe2x80x9cAltxe2x80x9d key on keyboards commonly used with the Microsoft Windows operating system, to perform a function. Keyboard accelerators allow a user to select a control without having to navigate a pointing device to it. However, the keyboard accelerators are again of little benefit to a heavy mouse user. Moreover, the keyboard accelerators can sometimes confuse the novice keyboard user because the use of the keyboard accelerators is not intuitive. Accordingly, a need exists for a system or method for displaying or not displaying keyboard cues, such as focus indicators and keyboard accelerators, based on whether a user is predominantly a keyboard user or a mouse user.
The present invention allows a computer system to hide user interface elements, such as keyboard cues, based on whether the user is a keyboard user or a mouse user. Briefly stated, when a window is created, the window queries the system to determine whether the input that created the window resulted from a keyboard input device or a mouse input device. The window either displays or hides the keyboard cues based on that determination. In other words, the system predicts whether the keyboard cues are helpful to the user based on the last navigation mode, i.e. whether the user caused the window to be created with a keyboard or a mouse. If the input device that resulted in the window creation was a mouse, the window initially hides the keyboard cues. In this manner, extraneous window clutter is decreased for the mouse user. If the input device that resulted in the window creation was a keyboard, the keyboard cues are likely desired by the user and therefore displayed.
The window may change the display state of the keyboard cues. For example, the window may have been created with the keyboard cues initially hidden. If the window notices that the user has begun navigating with the keyboard, the window responds by displaying some or all of the keyboard cues. In one example, if the user depresses the xe2x80x9cTabxe2x80x9d key to navigate from button to button or field to field, the window may display the focus indicator. In another example, if the user depresses the xe2x80x9cAltxe2x80x9d key, the window may display the keyboard accelerators.
As is known to those skilled in the art, a window may have child windows. Examples of child windows are push buttons, radio buttons, check boxes, list boxes, scroll bars, and text-entry fields. The user may interact directly with a child window with either the mouse or keyboard, possibly resulting in a change in the display state of the keyboard cues in the child window. In that situation, rather than handling the change directly, the child window may pass that information to a window manager which, in turn, passes a message up the window hierarchy to the top-level window. The message may indicate that a change in the display state is warranted based on the input device used to navigate within the child window. The message does not, however, directly cause the change in the display state. When the message reaches the top-level window, the top-level window requests an update of the display state for itself and all its child windows. The system then issues commands to all the windows in the window hierarchy causing each of them to change their respective display states. This aspect ensures that the top-level window and all child windows share the same display state for the keyboard cues. Otherwise, the child window may change its display state while the remaining windows in the window hierarchy do not, resulting in some keyboard cues being displayed while others are not.
In some situations, allowing a child window to prevent a change to the display state of the keyboard cues may be desirable. In that case, a child window, such as a control container manager, may be configured to intercept the message being passed up the window hierarchy before it reaches the top-level window. The window procedure for the intercepting child window may be configured to respond to the message in any conventional way but without continuing to pass the message up the window hierarchy. Because the message does not reach the top-level window, the display states of all the windows in the window hierarchy remains unchanged. Alternatively, the control container manager may issue another message to the window manager to have only those controls updated.